fix(purl): filter purl_statuses by SBOM describing CPEs [Backport release/0.4.z] - #2564

Please address the comments from this code review:

## Overall Comments
- The generalized CPE matching logic is now implemented both in the raw SQL constant and in the new SeaQuery builder for `allowed_cpe_ids`; consider extracting this into a shared helper or at least co-locating the logic so the two stay in sync when behavior changes.
- The aliases `c`, `sc`, and `sdc` in the generalized CPE query make the join conditions harder to follow; using more descriptive alias names (e.g., `concrete_cpe`, `sbom_cpe`, `sbom_cpe_link`) would improve readability and maintainability of this complex query.

## Individual Comments

### Comment 1
<location path="modules/fundamental/src/vulnerability/service/mod.rs" line_range="287-289" />
<code_context>
   jsonb_agg(
     jsonb_build_object(
       'status', status.slug,
-      'id', purl_status.advisory_id
+      'id', purl_status.advisory_id,
+      'context_cpe', purl_status.context_cpe_id
     )
   ) AS advisories
</code_context>
<issue_to_address>
**suggestion:** Consider naming the JSON key to reflect that it carries an ID, not a full CPE object.

The value here is `purl_status.context_cpe_id`, so the key name suggests a full CPE rather than an ID. Consider renaming the key (e.g. to `context_cpe_id`, or whatever matches existing API conventions) to avoid confusing downstream consumers about what this field contains.
</issue_to_address>

### Comment 2
<location path="modules/fundamental/tests/dataset.rs" line_range="97" />
<code_context>
     let ubi_details = ubi_details.unwrap();
     let ubi_advisories = ubi_details.advisories;
-    assert_eq!(ubi_advisories.len(), 1);
+    assert_eq!(ubi_advisories.len(), 3);
     assert!(
         ubi_advisories
</code_context>
<issue_to_address>
**suggestion (testing):** Strengthen this assertion to validate which advisories are present, not just the count.

Simply increasing the expected advisory count to 3 keeps the test brittle and not very descriptive. Since the broader CPE matching is intentional, also assert on which advisories are returned (e.g., IDs, statuses, or a subset) rather than only their number. This will make future failures more informative and clearly document which advisories are expected for ubi8.

Suggested implementation:

```rust
    let ubi_details = ubi_details.unwrap();
    let ubi_advisories = ubi_details.advisories;

    // Assert on the specific advisories we expect for ubi8, not just the count.
    let advisory_ids: std::collections::HashSet<_> = ubi_advisories
        .iter()
        .map(|advisory| advisory.id.as_str())
        .collect();

    let expected_ids: std::collections::HashSet<&'static str> = [
        "RHSA-YYYY:0001",
        "RHSA-YYYY:0002",
        "RHSA-YYYY:0003",
    ]
    .into_iter()
    .collect();

    assert_eq!(
        advisory_ids, expected_ids,
        "unexpected advisories for ubi8: got {:?}, expected {:?}",
        advisory_ids, expected_ids
    );

    assert!(

```

1. Replace `"RHSA-YYYY:0001"`, `"RHSA-YYYY:0002"`, and `"RHSA-YYYY:0003"` with the actual advisory IDs that are expected for the ubi8 test fixture in this test.
2. If the `Advisory` struct does not expose the ID as `advisory.id: String`, adjust the mapping closure `map(|advisory| advisory.id.as_str())` to use the correct field (e.g., `advisory.advisory_id.as_str()` or similar).
3. If you’d like to also assert on statuses or other fields, you can extend the `expected_ids` concept into a struct or tuple set (e.g., `(id, status)`) and map `ubi_advisories` accordingly before comparing the sets.
</issue_to_address>